Thin provisioned clone

ABSTRACT

A unified system provides primary storage and in-line analytics-based data protection. Additional data intelligence and analytics gathered on protected data and prior analytics are stored in discovery points. The disclosed system implements multi-threaded log writes across rimary and restore nodes with write gathering across file systems; nested directories such as may be used for storing virtual machine files, where every subdirectory has an associated file system for snapshot purposes; and cloning objects on demand with background metadata and data migration.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. Provisional PatentApplication Ser. No. 62/038,498 filed Aug. 18, 2014. This patentapplication also generally relates to co-pending U.S. utility patentapplication Ser. No. 14/017,754 filed Sep. 4, 2013 titled “SYSTEM ANDMETHOD OF DATA INTELLIGENT STORAGE”, U.S. utility patent applicationSer. No. 14/157,974 filed Jan. 14, 2014 entitled “LIVE RESTORE FOR DATAINTELLIGENT STORAGE SYSTEM” and U.S. utility patent application Ser. No.14/203,871 filed Mar. 11, 2014 entitled “CONSOLIDATING ANALYTICSMETADATA”. The entire contents of each of the above-referencedco-pending patent applications are hereby incorporated by reference.

BACKGROUND

Discussed herein are techniques applicable for a High Availability (HA)storage system that collects analytics while also protecting data onseparate physical media. The analytics may enable other functions suchas data intelligence. In such a system as described in the referencedpatent applications, primary data is read from and written to a primarystorage pool. As the data is written to the primary pool it isautomatically mirrored and also tracked for data protection to arecovery pool. The mirror can also be used for intelligence includinganalytics stored as discovery points.

BRIEF SUMMARY

More particularly, the techniques disclosed herein relate to a systemthat merges primary data storage, data protection, and intelligence intoa single unified system. The unified system provides primary and restoredata, analytics, and analytics-based data protection without requiringseparate solutions for each aspect. Intelligence is provided throughinline data analytics, with additional data intelligence and analyticsgathered on protected data and prior analytics, and stored in discoverypoints, all without impacting performance of primary storage.

More particularly, the disclosed system implements:

-   -   multi-threaded log writes across primary and restore nodes;    -   nested virtual machine directories, where subdirectories are        associated with a virtual structure that corresponds to a file        system for snapshot purposes;    -   file system clone available on demand with background metadata        and data migration; and/or    -   write gathering across file systems/nodes.

In one embodiment, that multi-threaded log writes are implemented at aprotection and analytics (PART) node. The PART node receives accessrequests from multiple concurrently executing threads, and assigns atransaction identifier (ID) to the access requests. The PART thencollects the access requests in a random access, multithreaded logbefore sending them to both a primary and a restore storage system.Subsequently, the PART forwards the access requests from the PART nodeto the primary node and restore node.

The PART may further optionally determine when a number of accessrequests in the random access, multithreaded log reaches a predeterminednumber. At that time, the PART issues a synchronization command to theprimary and restore nodes which causes data to be flushed fromrespective temporary caches to a persistent file system in each of theprimary and restore. Once data is confirmed as having been flushed inboth the primary and restore nodes, the PART may then release entries inthe random access, multithreaded log.

Another aspect is particularly useful where the system is to supportsnapshot and other actions applied to virtual machine definition filesarranged in subdirectories. Here the PART maintains a set of file systemlevel objects, one for each subdirectory in a directory tree created byan application, such as a hypervisor. The PART intercepts a makedirectory request from the application to store a new a file systemlevel object for each subdirectory in the tree. The file system levelobject contains access information for the corresponding subdirectory,such that multiple make directory requests result in storing acorresponding multiple number of file system level objects as a virtualfile system.

Subsequently received access requests for applying a file system actiona file system object located with a subdirectory are then serviced bythe primary and restore nodes using only the virtual file system levelobject information and not the subdirectory directly. This ensures thatthe virtual file system objects remain transparent to the application.

In this arrangement, a property may be associated with two or morevirtual file system objects to indicate that an access request appliesto two or more subdirectories as a consistency group.

In another embodiment, the data-intelligent storage system intercepts arequest to clone a data object. A clone object is first thin provisionedand opened for access. Data is copied to the clone object only upon thefirst to occur of either (a) a subsequent access request for the cloneobject, or (b) as part of a background restore process. Thinprovisioning may involve creating a bitmap data object containing a bitfor each one of a plurality data chunks in the data object.

Bits may be set in the bitmap corresponding to data chunks referred toin the subsequent access request for the clone. In such an instance, thebitmap is updated as data chunks are copied to the clone object.

A separate process for handling temporary clone objects uses the bitmapsto determine when to access the original object, the clone, or asnapshot.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, closely related figures and items have the same numberbut different alphabetic suffixes. Processes, states, statuses, anddatabases are named for their respective functions.

FIG. 1 is a diagram showing interaction between a Primary Node,Intelligence Node, and Remote Intelligence Node, and connected storagepools.

FIG. 2 is a view of an appliance device containing Primary andIntelligence Nodes.

FIG. 3 is a diagram showing the components of a Primary Node.

FIG. 4 is a diagram showing the components of an Intelligence Node.

FIG. 5 is a diagram showing the analytics flow process.

FIG. 6A is a diagram showing the structure of a change catalog.

FIG. 6B shows a discovery point.

FIG. 7 is a diagram illustrating a multi-threaded log.

FIG. 8 shows a process flow for handling an access request at the PART.

FIG. 9 shows a process flow for synchronizing requests to releaseentries in the multi-threaded log.

FIG. 10 shows write access gathering at the PART.

FIG. 11 shows virtual file system objects representing virtual machinesubdirectories created by a hypervisor application can be submitted to asnapshot process.

FIG. 12 shows a more general case where an action is applied in arestore node across subdirectory trees and file objects stored withinthose directories.

FIG. 13 is a high level diagram of a system that provides clone ondemand with background migration of data and metadata.

FIG. 14 illustrates a file object and corresponding clone bitmap.

FIG. 15 is a process flow for creating a clone of a file object.

FIG. 16 is a process flow for access a cloned file object.

FIG. 17 shows a directory tree object and its corresponding clone.

FIG. 18 is a process flow for creating a directory object.

FIG. 19 is a process flow for accessing a temporary clone directoryobject.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT Terminology

The terminology and definitions of the prior art are not necessarilyconsistent with the terminology and definitions used herein. Where thereis a conflict, the following definitions apply.

Primary Storage: networked storage accessible to multiplecomputers/workstations. The storage can be accessed via any networkeddevice, either as files or blocks. Unless explicitly stated, “primarystorage” refers to both blocks and files.

Intelligence Storage: secondary storage containing gatheredintelligence, discovery points, and a redundant real-time copy of filesand block data contained in Primary Storage.

Primary Node: includes access protocols to communicate with anIntelligence Node, Remote Sites, and Expansion Nodes; access protocolslayer (for example, NFS, SMB, iSCSI); protection and analytics inreal-time (“PART”) layer; file and block storage layer (file system,block volume); and connection to storage devices (RAID, DISK, etc.). APrimary Node appears to system users as Primary Storage, and provides aninterface and controls to act as the access to Intelligence Storage.

Intelligence Node: includes access protocols to communicate with aPrimary Node, Remote Sites, and Expansion Nodes; data intelligencestorage layer (intelligent data services & rules processing); file andblock storage layer (file system, block volume); and connection tostorage devices (RAID, long-term storage). In the preferred embodiment,intelligence node data is accessed by users through a Primary Node, butin alternate embodiments Intelligence Nodes may be directly accessed byusers.

Discovery Point: A discovery point, created from a mirrored (highavailability) copy of primary data, contains data analytics for accessedand changed primary data since a prior discovery point. A discoverypoint may contain the changed data, providing for a virtually full butphysically sparse copy of the primary data captured at a user-specifiedpoint in time or dynamically based on change rate or other analytics.While primary data does not change within a discovery point after thediscovery point was created, analytics metadata stored in a discoverypoint can be expanded as deeper levels of user data analysis areperformed and more analytics are gathered. Tracked primary data changescan be retained for the life of the discovery point or can be removed atscheduled or dynamic intervals, such as after deep data analysis iscomplete and desired analytics metadata is obtained. Removing primarydata allows for more efficient space utilization, while retainingprimary data enables point-in-time recovery of that version of data.

Change Catalog: an ordered set of real-time access and changeinformation related to a data object, tracked at a discovery pointgranularity. A change catalog tracks who, how, when, and where aspectsof a data object being accessed and/or modified. There is one changecatalog for every discovery point.

Remote Site: one or more off-site nodes in communication with local siteprimary or intelligence nodes.

Pool: the collection of data storage connected to a node.

Object: a file, directory, share, volume, region within a volume, or anembedded object. Objects can be complex, containing other embeddedobjects. For example, a file can be a container containing other files,or a volume can have a file system on top of it which in turn containsfiles. The system is capable of recognizing complex objects and trackingchanges at finer embedded object granularity.

Selective Restore: an automatic (policy based) or manual (customerinitiated) restore at an object level.

Site Restore: a manually initiated process to recreate primary orintelligence pool content using a previously protected version of thedata being restored.

Container: objects which may have other embedded objects, such as afile, directory, file system, or volume.

Expansion Nodes: appliance having a processor, memory (RAM), networkconnectivity, and storage devices, and connected to one or more primaryor intelligence nodes scaling the processing power and/or storage forconnected nodes.

System Overview

In the following detailed description, reference is made to theaccompanying drawings which form a part hereof, and in which are shown,by way of illustration, specific embodiments in which the invention maybe practiced. It is to be understood that other embodiments may be used,and structural changes may be made without departing from the scope ofthe present invention as defined by the claims.

The disclosed high availability (HA) storage system provides primarystorage, analytics, and live restore functions. Live restore is atechnique used to optimize data restoration. It can be used to recoveruser data in case of a failure or to recover previous versions of theuser data. The system provides primary storage access as block and/orfile level storage while avoiding single points of failure. The systemcollects analytics in real-time while also protecting data in real-timeon separate physical media, and includes options for off-site dataprotection. The system implements deep analytics enabling restore,storage, and data intelligence, and protects both customer data andassociated analytics. The system provides traditional file based andcustom API methods for extracting analytics metadata. The system employsLive Restore techniques at a file and at a block level to recover incase of a failure or to recover a previous version of user data. Thisprovides for near-instantaneous restore at the object level, andsignificantly reduces wait-before-access time in case of primary orintelligence node complete failure (e.g., a full site restore). A fileor block level Live Restore uses previously gathered analytics toprioritize data to be restored, while allowing user I/O access to thedata during restoration.

Referring to FIG. 1, Primary Node 100 of the system connects within anetwork to provide block and/or file level storage access to connectedcomputing devices (not shown), real-time data protection, and real-timeanalytics of primary data. Primary data is read from and written toprimary storage pool 110. The data can be written or read as files orblocks depending on the access protocol being used. As the data iswritten it is automatically mirrored and tracked for data protection aspart of a HA process for the primary node. The mirrored cache of thedata is created for Intelligence Node 120. The Intelligence Node enablesdata protection, analytics, and recovery. The Intelligence Node stores areal-time copy of primary data, analytics and discovery points withinintelligence pool 130. Discovery points are automatically or manuallycreated at any point by the Intelligence Node, and based on fine grainedchange data enabling action to be taken immediately with no need to copythe underlying primary data or do any post processing to determine whathas changed since any prior discovery point.

In a preferred embodiment, each Node is capable as acting as either aPrimary Node, an Intelligence Node, or both. For reliability andperformance reasons, separate Primary and Intelligence Nodes aredesirable. In case of failure of either node, the other may take overoperation of both. Implementation without dual-capability (that is,operating solely a Primary Node and solely an Intelligence Node) ispossible but loss of service (to either primary or intelligence storage)would occur on failure of such a node. In a preferred embodiment, eachone of the Nodes has a processor and local memory for storing andexecuting Node software, a connection to physical storage media, and oneor more network connections including at least a dedicated highbandwidth and low latency communication path to other Nodes.

In a preferred embodiment, the Primary Node and Intelligence Node arephysically housed within a single device, creating a user impression ofa single appliance. FIG. 2 shows one such example, with Primary Node 100and Intelligence Node 120 housed together to appear as a single physicalappliance. Implementation may be with any number of disks, for examplesuch as a four rack units (4 U) housing containing up to twenty-fourhard drives, with separate physical storage devices connected to thesystem. Internally each node is completely separated from the other withthe exception of a backplane, with each node having a dedicated (notshared) power supply, processor, memory, network connection, operatingmedia and optionally non-volatile memory. Separation enables continuedoperation, for example the Intelligence Node may continue operatingshould the Primary Node fail, and vice versa, but shared resourceimplementation is also possible.

Primary Node

Also referring to FIG. 3, a node actively operating as Primary Node 100operates storage protocol server software 300, for example CommonInternet File System (CIFS), Network File System (NFS), Server MessageBlock (SMB), or Internet Small Computer System Interface (iSCSI), so thePrimary Node will appear as primary storage to network-connectedcomputer devices. The storage protocol server software also communicateswith a protection and analytics in real-time process (PART) 310 whichintercepts and takes action on every data access.

The PART 310 performs three main roles after intercepting any dataaccess request: mirroring primary data for HA, gathering in-line dataanalytics on primary data, and storing primary data. The examplesexplained herein are directed to a file access perspective, but the PARTcan similarly process block level accesses. When performing block accessto a volume, the PART can identify embedded objects and perform the sameanalysis that is applied to file-level accesses. Intercepted accessrequests include read, modify (write data or alter attributes, such asrenaming, moving, or changing permissions), create, and delete. The PARTtracks and mirrors the request (and data) to the Intelligence Node.Communication with the Intelligence Node is through synchronous orasynchronous inter-process communication (IPC) 340 depending onconfiguration. IPC may including any suitable protocols or connections,such as Remote Procedure Call (RPC) or a Board-to-Board (B2B) highperformance, low latency communication path that may be hardwarespecific. Any data included with a data access request, such as includedin write operations, is also mirrored to the Intelligence Node as partof HA system operation. This mirroring establishes data protectionthrough real-time redundancy of primary storage. Additionally, the PARTexecutes in-line analysis of primary data, gathering real-timeanalytics. The PART sends gathered real-time analytics to theIntelligence Node, where the analytics are added to a change catalogmaintained by the Intelligence Node. In addition to analytics, the PARTdirects the request to an actual file system, for example FourthExtended File System (EXT4) or Z File System (ZFS), or block volume forfile or block storage access 330 to physical storage devices.

The storage access function 330 (be it file system level or block level)performs the access request on storage media, and returns the result tothe PART for return to the requesting system. In a preferred embodiment,the storage media includes disks attached to the system, but otherstorage media solutions are possible.

In a preferred embodiment, the Primary Node also includes the softwarenecessary to operate as an Intelligence Node in case of IntelligenceNode failure.

In a preferred embodiment, the Primary Node also operates managementsoftware. Preferably accessed through a browser interface (although anyuser interface provision method may be used), the management softwareprovides system administrators access to configure and manage systemusers and access discovery points for the restore process.

Intelligence Node

Referring also to FIG. 4, a node actively operating as Intelligence Node120 operates Inter Process Communication (IPC) communication software400 capable of communicating with the Primary Node. The communicationsoftware includes an API to receive real time analytics (change catalogentries) from the Primary Node, data change and access requests (read,modify, create, delete) from the Primary Node, data protection andintelligence control commands, and data restore commands. Dataprotection and intelligence control commands include commands forcreating discovery points, setting up management rules for managingdiscovery points (including deletion), and searching and restoringcontent that has been backed up. Data restore commands include commandsfor accessing previously backed up data.

Data change requests that are received at the Intelligence Node areapplied to that node's copy of current data, thereby maintaining areal-time mirror of primary storage. This implements real-time dataprotection for the current data.

For data analytics and data recovery purposes, the Intelligence Nodemaintains a change catalog 600 containing real-time analytics gatheredfrom accessed and changed data since the last discovery point 650. Adiscovery point is also created by associating and storing a changecatalog together with reference to the mirrored copy of changed primarydata since the last discovery point as maintained in the intelligencepool. A more detailed discussion of the change catalogs and discoverypoints is provided below.

The Intelligence Node implements file or block-level access 430 to itsown pool 130 of physical storage. This intelligence storage pool retainsthe real-time copy of primary data and discovery points. The storedintelligence data within discovery points includes in-line analytics(change catalog) as received from the Primary Node and additionalanalytics 410 executed by the Intelligence Node.

The real-time copy of primary data also enables distributed responseprocessing between the Primary and Intelligence Nodes. For example, loadbalancing between the Primary and Intelligence Nodes may enable greaterscalability. As both have real-time copies of primary data, readrequests may be balanced between the nodes, or alternatively directed toboth nodes with the fastest-to-respond used for the response. ThePrimary Node may act as a controller for such distributed processing, ora separate controller may be used.

There is no requirement that the Primary 110 and Intelligence Data 130reside on the same appliance, they can be distributed to multiplediscrete appliances deploying all the same techniques with the exceptionthat the communication method is performed over a network transportinstead of using the HA mechanisms within an array.

Analytics

Intelligence is at the core of the system. There are four types ofintelligence functions in the system: Data, Operational, Storage, andRecovery. All four use the same processing engine and common analyticsmetadata to provide analysis both at fixed points and as gathered overtime. Data Intelligence 452 allows for intelligent user contentmanagement. Operational Intelligence 456 analyzes the behavior of thesystem and application logs stored on the system to provide insight intoapplications and security of the system. Storage Intelligence 454 allowsfor intelligent storage system resource management, including automaticstorage allocation and reallocation including dynamically growing andshrinking storage pools. Recovery Intelligence 450 allows forintelligent data protection and data restore. All types of intelligencemay be used for, or enable operation in conjunction with, differenttypes of analytics, such as, but not limited to, collaboration,trending, e-discovery, audits, scoring, and similarity.

Analytics begin at the Primary Node, which tracks data access and datamodifications, system behavior, change rates, and other real-timeanalytics. It provides this real-time analytics information to theIntelligence Node. Intelligence gathering determines time and ownerrelationships with the data for collaboration and contextual informationabout the data. The gathered intelligence is used for later search andreporting, and is tracked in change catalogs associated with the data.

Referring now to FIG. 5 and to FIG. 6A, change catalogs 600 are createdas part of in-line real-time analytics 500 performed by the Primary Node100, but change catalogs 600 are then also further expanded by theIntelligence Node 120 performing further data processing, and create thefoundation for later search. The change catalog data is initiallycreated in real-time at the Primary Node (such as via PART 310) andincludes extended information about the specific data access, forexample, allowing complete tracking of who/how/when/where accessed,created, modified, or deleted a file or other data object. Traditionalfile metadata includes only an owner, group, path, access rights, filesize, and last modified timestamp. This provides some, but not complete,information about a file. For example, it does not identify who modifiedthe file, how many modifications have occurred, or any information aboutfile accesses (such as viewing or reading a file) which do not modifythe file. The PART, operated by the Primary Node, intercepts every fileaccess event. Thus the Primary Node has the ability to track extendedmetadata about a file—including identification of every modification andevery access, even those which do not modify the file, by timestamp,user, and type of access.

Referring also to FIG. 6A, this extended metadata is stored as a changecatalog entry 610 that identifies the object being accessed, the actor(user performing an operation), and the operation being performed.Additional information which may be in a change catalog entry includes,but is not limited to, object name, owner, access control lists, andtime of operation. The change catalog 600 contains this extendedmetadata information, and serves as the foundation of further analytics,such as performed later by the Intelligence Node. The change catalogentry may also include security information, such as permission rightsfor access, associated with the object. An administrator may configurethe degree of tracking, or even enable/disable tracking on a filelocation, user, group-specific, or other basis, and the Primary Node iscapable of incorporating all details of every file access into thechange catalog entries. These change catalog entries of enhancedmetadata are gathered by the Primary Node and transmitted to theIntelligence Node for storing and expanding with further analytics.

With reference now also to FIG. 6B, the change catalog metadata tracksincremental changes which are also linked to a discovery point 650.Every time a new discovery point is created the current change catalogis closed off and stored within the discovery point. When data isretained in the discovery point, the system may be configured to retaina copy of the discovery point analytics metadata at the IntelligenceNode even if that discovery point is migrated off the Intelligence Node,enabling more efficient query processing.

A discovery point 650 is created by associating and storing a changecatalog together with the mirrored copy of changed primary data sincethe last discovery point in the intelligence pool. After a discoverypoint creation, a new change catalog 600 is created allowing gatheringof new real-time analytics on primary data. Change catalogs anddiscovery points are preferably maintained per volume or file system inprimary storage, but may also span multiple volumes or file systems.Discovery points allow deeper analytics on a point in time version ofprimary data, and can also be used to recover a prior version of primarydata. A discovery point contains data analytics for accessed and changeddata since a prior discovery point. When created, a discovery point alsocontains a virtually full but physically sparse copy of primary data atthe time of creation of that discovery point. The system uses datavisible within discovery points to perform deeper data processing,creating more analytics metadata. The analysis is done on accessed andchanged data since a previous discovery point, using the real-timeanalytics reflected in the change catalog. These newly gathered deeperanalytics are also stored within the discovery point. Primary data maybe retained for the life of the discovery point, or may be removedearlier, such as after the deep data analysis is complete and desiredanalytics metadata obtained. Removing the primary data allows for moreefficient space utilization, while retaining the primary data enablesrecovery of primary data at the point in time of the creation of thediscovery point. From one discovery point until the creation of a nextdiscovery point, file changes, deletions, renames, creations and suchare tracked as cumulative modifications to from the prior discoverypoint, so that only incremental changes are maintained. This creates aversion of the data at each discovery point. While the data is retainedin a discovery point, the system is able to restore data at thediscovery point granularity. As change catalogs are stored with eachdiscovery point, information about change history between discoverypoints may be available through analysis of the change catalog. Torestore a data object at a particular point in time, a discovery pointis used. For long-term storage, discovery points may be moved tolong-term media such as tape or off-site storage as configured throughthe management software.

Discovery points can be deleted manually through a delete discoverypoint command, or automatically based on time or analysis in order tosave storage space or for off-site migration. Deletion of discoverypoints is complicated by management of analytics metadata. The analyticsmetadata stored within a discovery point contains information about datachanged within a period of time. If the stored analytics are deletedthey can be lost. To prevent this, the time period for analyticsassociated with one or more other discovery points can be adjusted, andrelevant portions of analytics metadata from a discovery point beingdeleted extracted and merged with other analytics already stored withinthe other discovery points.

Returning attention now to FIG. 5, at the Intelligence Node, an adaptiveparallel processing engine, or Rule Engine 420, operates on the changecatalog 600 to derive these more complex analytics, including trackingchanges and use over time. The Rule Engine applies rules 510 to analyzecontent on the underlying primary data, enabling deeper analytics onstored data. As an example, a second level dictionary can providesentiment attributes to an already indexed document. Regular expressionprocessing may be applied to see if a document contains information suchas social security or credit card numbers. Each rule may have a filter530 to match content, and an action 540 to take based on results. Rulescan be nested, and used to answer user-specific questions. Anotherexample may be to apply locations where keywords appear, for example tosearch objects for a set of keywords such as “mold” or “water damage,”and in all matches to search the objects for address or zip codeinformation. Rules are configurable by administrators or system users,allowing dynamic rule creation and combination based on differentapplicable policies 520. Rules can be combined in multiple ways todiscover more complex information. Rules may also be configured foractions based on results. For example, notifications may be set totrigger based on detected access or content, and different retentionpolicies may be applied based on content or access patterns or othertracked metadata. Other actions may include, but are not limited to,data retention, quarantine, data extraction, deletion, and datadistribution. Results of applied rules may be indexed or tracked forfuture analysis.

As applied rules 510 identify results, such results may be indexed ortracked for other analytical use. This additional metadata may be addedto the change catalogs for the relevant files or objects. The metadatamay also be tracked as custom tags added to objects. Tags may be storedas extended attributes of files, or metadata tracked in a separateanalytics index such as data in a directory or volume hidden from normalend user view, or in other data stores for analytics. Rules, andtherefore analytics, may be applied both to data tracked and to themetadata generated by analytics. This enables analytics of both contentand gathered intelligence, allowing point-in-time and over-timeanalysis. The rules results and actions may serve as feedback from oneor more rules to one or more other rules (or even self-feedback to thesame rule), enabling multi-stage analysis and workflow processing.

Recovery Intelligence 450

Recovery Intelligence is the set of analytics implemented byIntelligence Node 120 around data protection. The purpose is to protectdata and associated analytics. When data reaches the Intelligence Node amirrored copy is stored in the intelligence pool, creating redundancywith primary storage, and these changes are tracked for use in discoverypoint creation. Primary data, discovery points, and intelligence dataare preferably separated on actual physical media at the spindle or diskpool level, such that a failure of a single individual physical deviceis always recoverable. As discovery points are created based on changecatalogs tracked at the Intelligence Node, they can be created at anytime without any impact on the performance of primary storage. Thiseliminates a need to schedule time-windows for discovery point creation.Each discovery point includes incremental changes from the priordiscovery point, including data object changes and the analyticsgathered and associated with the data during such changes. Intelligentrules can be applied to automate discovery point creation, such that, inaddition to manual or time-based creation, discovery point creation maybe triggered by content changes. Such changes may be percentage based,specific to percentage change of certain identifiable subsets of theentire data pool, based on detected deviations from usage patterns suchas increase in frequency of specific accesses, or based on real-timeanalysis of data content.

At the creation of a discovery point, the change catalog accumulatingreal-time changes is closed. The change catalog is then stored withinthe created discovery point, and a new change catalog created forchanges to be associated with a next created discovery point. Theanalytics and data stored within discovery points enable efficientrestores, allowing search over multiple discovery points for specificobject changes without requiring restoration of the data objects fromeach discovery point. Such search can be based on any analyticsperformed, such as data tracked in the extended metadata andcontent-based analysis performed by application of the Rule Engine. Thetracking further enables indexing and partial restores—for examplespecific objects, or embedded objects within complex objects, can berestored from a discovery point without a complete restore of all datafrom that discovery point.

Data Intelligence 452

Data Intelligence is a set of analytics at the Intelligence Nodeanalyzing content. Data Intelligence operates through the Rule Engine,and can be applied to unstructured data, for example file metadata suchas document properties of Microsoft Office documents or the actualcontent of such documents, semi-structured data such as log files orspecific applications such as Mail programs, structured data such asdatabases or other formats for which schema may be known or discoveredby the system, and recursive containers such as virtual machines, filesystems on file systems, file systems on volumes, or archives.

Multi-Threaded Transaction Log

File systems use internal data structures, called metadata, to managefiles, directories and data in files. A typical file system uses loggingto guarantee crash consistency. One of the popular techniques toguarantee crash consistency is a write-ahead log. Before modifyingmetadata, the file system logs the intent of modifications to the log,and then performs the metadata modifications on disk. In case of apanic, power failure, or crash, the log is then replayed to bring thefile system back to a consistent state.

Consider a high availability, data intelligence environment as shown inFIG. 7. As explained above, the PART 310 intercepts data accessrequests, forwards them to a primary node, mirrors them to a highavailability restore node, and performs analytics to create intelligencedata. During these operations, each of the primary node 100 and restorenode 140 operate with their own independent file system 102, 142 (FS).It should be understood that the file systems 102, 142 may be aZFS-compatible file system or some other file system.

Certain types of file systems (FS) on each of the primary 100 andrestore 140 may maintain their own local log (101, 141) of transactions;however other file systems may not maintain such local logs 101, 142 ormay find it convenient to disable them. Also, when such file systemtransaction logs (101, 141) might typically be single threaded such thatall log writes are guaranteed to be sequential. A logged transactionincludes all the metadata modifications that will be done as part of anI/O. For example, if an I/O operation allocates on indirect block, thelog entry in 101 or 141 consists of the new allocated indirect block,the parent indirect block where the new block will be inserted, anoffset in the parent indirect block, the inode where associated with theindirect block, and so on.

Since some transactions take longer than others to process, the singlethreaded, sequential log process delays any subsequent log transactionsfrom being entered when the log is busy with a prior task.

In a preferred implementation, the PART 310 maintains its own log 311independent of the logs 101, 141, if any, as maintained by the filesystems 102, 142 in primary 100 and restore 140 nodes. This PART-level,“virtual file system” log 311 is implemented in a durable storage mediumthat can be written to in random order, such as nonvolatile memory. Toachieve crash consistency, access requests can be replayed at theprimary 100 and restore 140 nodes consistent with the original order inwhich they were received at the PART 310. In some implementations, thePART log 310 may obviate the need for logs 101, 141, which then may bedisabled or bypassed if the file systems 102, 142 allow this.

More specifically, any metadata in the PART log 311 is stored with acorresponding transaction ID. The transaction IDs are a unique numbermaintained by the PART 310 and incremented upon each access requestreceived. Writes to the PART log 311 may therefore be multithreaded suchthat they can be written any time and in any order, with the orderinformation retained in the transaction ID associated with each request.

FIG. 7 shows a typical PART log entry including a transaction ID, anoperation type, a file handle, offset, length and data. The entries inthe PART log 311 are arranged in a number of chunks 301 typically witheach chunk being of equal size to other chunks.

As mentioned previously, access requests received by the PART 310 may bemultithreaded. The various chunks 301 in the PART log 311 enable logentries to be written in any order and also concurrently. As a result,writes to the random access, high speed PART log 310 do not have toobserve any ordering dependencies, yet the ordering can be regeneratedwhen the PART log 310 is replayed to the primary and restore nodes.

In one example shown in FIG. 7, the PART 310 is executing five (5)concurrent threads labeled A1, A2, A3 and B. In this example, some ofthe threads are issuing access requests for a data tree structure thatis to be populated with engineering data concerning the configuration ofa manufactured component. Other threads executing in the PART 310 areconcerned with processing customer orders for the component. Forexample, a first thread A1 may be responsible for creating the treewhile threads A2 and A3 are responsible for writing data to the tree. Inthis example, thread B is handling an entirely different operation suchas supporting database accesses concerning the customer orders for thecomponent. Thus it should be understood that some of the accesses (thoseinitiated by threads A1, A2, A3) will ultimately have to be executed ina certain order at the primary 100 and restore 140 nodes, but otheraccesses (thread B) can be handled in any order at the primary 100 andrestore 140 level.

However, regardless of the order in which the accesses must ultimatelybe executed at the primary 100 and secondary 140, the accesses can bewritten to in any order in the PART log 311. This is because, aspreviously described, the transaction ID numbers are assigned to eachaccess request in the order which they are received. This then enablesthe transactions to be executed in the correct order in the local filesystems 102, 142, even though they may have been originally stored inrandom order by the multiple threads executing at the PART level 310.

After each access request is written to the PART log 311, it isforwarded in parallel to each of the primary 100 and restore 140 nodes.The primary 100 and restore 140 nodes then copy the request data to arespective local cache 104, 144, but do not yet actually issue therequest to their underlying file systems 102, 142 to access permanentstorage such as respective disks 103, 143. Without the PART log 311,such behavior by primary 100 and restore 140 nodes would not providecrash consistency locally within file systems 102, 142, and also doesnot provide consistency between file systems 102, 142.

At some time when the number of entries in the PART log reaches acertain number (such as when the PART log 311 is nearing a fullcondition), the PART 310 issues a synchronization (“sync”) request tothe primary 100 and restore 140. Upon receipt of the sync request, theprimary 100 and restore 140 flushes their respective cached data todisks 103, 143. The primary 100 and restore 140 then acknowledge thesync back to the PART 310. With the data now confirmed as having beenbeing persisted on disk by both the primary and restore nodes, the PART310 can now free the corresponding chunks 301 in PART log 311. In otherwords, it is not until the sync command is complete that data related tothe requests is known to be correctly persisted to respective disks inthe primary and restore nodes.

FIG. 8 shows a typical process flow among the PART 310 and primary node100. It should be understood that the corresponding operation betweenthe PART 310 and the restore node 140 is similar. In a first step 801the PART 310 receives an access request from a host. In a next step 802the PART assigns a next available transaction ID to the request. At step803, the access request is then written to any available chunk in thePART log 311. In next step 804, the request is then sent to both theprimary 100 and restore 140 nodes.

In step 841 the primary 100 receives the request from the PART 310. In anext step 842, if the primary 100 and restore nodes maintain a local log101, 141, they determine a place for the transaction in their respectivelog order from the transaction ID (which is known to have been assignedin the same order in which multithreaded PART receive it). At this pointin state 843 data associated with the request is stored in the primary'slocal cache memory 104,144. Although data is not yet stored on disk, instate 844 the primary can send an access complete acknowledgment back tothe PART 310. In state 850 the PART 310 can then report that fact thatthe access is logically complete even though the data has not yet beenflushed to disk at the primary 100. This permits the client applicationwhich is accessing the PART 310 to continue its logical flow even thoughthe data has not yet been physically flushed to disk. It should beunderstood from the foregoing that multiple instances of this processcan occur in parallel, owing to the multi-threaded nature of the PARTlog 311 which supplants the single-threaded logs 101, 141.

FIG. 9 illustrates the process flow between the PART 310 and the primary100 and restore 140 when the multithreaded log 311 is full or nearlyfull. In state 910 the PART 311 log is recognized as no longer beingable (or soon to become unable) to store additional requests. In step911, a sync command is sent from the PART 310 to both the primary 100and restore nodes 140. In state 920 the primary 100 (or restore node140) receive the sync command and in state 922 they flush their localcache to permanent file system (FS) storage such as one or more disk(s).Once the flush operation is complete in state 923, an acknowledgment canthen be returned to the PART 310.

In state 930 the PART receives the acknowledgment from the primary 100,and at some point (either prior to, at the same time, or subsequent tostate 930) the PART 310 also receives an acknowledgment from the restorenode 140. In state 933 having received flush acknowledgments from boththe primary 100 and the restore 140, the PART 310 can finally releasethe associated chunks 301 in PART log 311.

As a result, even when log entries are not recorded in PART log 311 inthe same exact order in which they are issued to the primary 100 andrestore 140 nodes, the transaction IDs can be used to replay the log inthe same order as the original writes occurred. The durable storage usedfor the PART log 311 is a fast access storage device, such as a solidstate device, so that the log file can be sorted in transaction ID orderas quickly as possible when it needs to be read back, such as when afault occurs before data is flushed to disk by both the primary 100 andrestore nodes 140.

This results in guaranteeing file system consistency at the highersystem level, and without relying on the standard log operations withinthe file systems implemented in both the primary node 100 and restorenode 140. This also guarantees data synchronization and metadataconsistency between the primary node 100 and restore node 140, even inthe event of an error occurring prior to cache flushing. Furthermore, ina case where primary and restore maintain their own logs 101, 141, thePART log 311 in effect becomes a virtual file system (VFS) log thatsupplants the operation of local logs 101, 141.

Write Gathering at Virtual File System Layer

It is typical for a storage system to aggregate write operations in acache before being flushed to main storage. Consider the environmentshown in FIG. 10. As with the systems described above, a dataintelligent storage system is implemented with a primary node 100 andhigh availability/intelligence data stored at restore node 140. In atypical I/O operation, a write access request may come into the PART310, and recorded in a PART log 311 before being forwarded to primary100 file system and restore 140 file system. In an optional arrangementthe primary and restore file systems may maintain their own logs 101,141 as previously described. In such an arrangement, those file systemlevel logs 101, 141 are also copied to a remote disk such that itanother remote copy 151 is made of the primary log 101 and anotherremote copy 105 is made of the restore log 141. As a result, each singleI/O transaction may result in many different write operations todifferent primary data stores and logs.

We have realized that efficiency can be obtained by also gathering writeaccesses at the PART 310 layer above the FS layers (102, 142)distributed to multiple nodes. A PART level cache, which we refer to asa write gathering cache 333, is implemented to store data associatedwith write requests. Thus when a write transaction comes into the PART310, the associated data is immediately copied to the write gatheringcache 333, and the I/O request is also acknowledged. Certain otheroperations that involve metadata, such as a make directory (mkdir)operation, are first logged in the PART log 310 and then issued to theprimary 100 and restore 140.

Writes are then aggregated in cache 333 until such time as the cache 333needs to be flushed to the restore node 140. At this point, for example,a sequence of transactions has resulted in multiple writes to the sameblock, the cache location associated with that block will be overwrittenmultiple times. Flushing of the gathering cache 333 will only thenrequire a single write of that block, thereby reducing the total numberof write operations to the restore file system 140. As part of the cacheflushing, additional copies can be sent to still other nodes, such as toprovide remote replication.

Virtual File System Supporting Subdirectory Snapshots and Other Actions

FIG. 11 shows the data intelligence storage system being accessed by oneor more applications 1010. In the particular example illustrated, theapplication 1010 is a hypervisor environment such as an ESX or ESXiserver (ESX and ESXi are trademarks of VMware, Inc. of Palo Alto,Calif.). The application 1010 creates and maintains various virtualmachine (VM) files in such an environment on a subdirectory basis. Forexample, the application 1010 expects a first virtual machine (VM0) tobe disposed within a first subdirectory (/vm0), and includes associatedvirtual machine files a0.vmdk, a1.vmdk, etc. The files associated with asecond virtual machine (b0.vmdk) are to be disposed within seconddirectory (/vm1), and the files associated with an (n−1)'th virtualmachine in subdirectory (/vmn). The files (k0.vmdk) associated with yetanother virtual machine are to be stored in a directory (/vm11) that issubordinate to directory /vm0. As can be seen, the ESX serverapplication 1010 may therefore be hosting a number of virtual machines;the data associated with each virtual machine including its operatingsystem image files, application files and associated data are stored inone or more files arranged in a directory tree 1011 within a single filesystem 1015 tree.

As with the other data intelligence environments discussed herein,application 1010 issues access requests to the PART 310. In turn, PART310 not only sends the access request to one or more file systems onprimary node 100, but also sends the access request to the filesystem(s) on restore node 140.

As explained above it also becomes desirable to use intelligence 145 inthe restore node 140 to perform certain tasks. One such task createsintelligence data in the form of a change catalog entry with associateddiscovery points (1020-1, 1020-2). In the scenario shown in FIG. 11,these discovery points 1020 may include snapshots of the state of thevirtual machine files and their associated data, metadata, otherintelligence data, and change catalog. As also explained above,snapshots become discovery points includes one or more snapshots of eachVM.

While certain applications such as the ESX server 1010 store theirassociated files in a tree structure 1011 containing differentsubdirectories, the file systems implemented with primary 100 and/orrestore node 140 may not easily support taking a snapshot of just asingle subdirectory and therefore of just a single VM. Such existingsnapshot technologies are directed to instead storing a snapshot of anentire file system. However it may be desirable in certain circumstancesto enable the use of such snapshot technologies on a single VM.

The basic idea is for PART 310 to identify particular applications suchas ESX server 1010 that create subdirectories, such as those containingvirtual machine files, and manage them in a distinct way. The PART 310therefore can more efficiently enable certain actions by intelligence145. As shown in FIG. 11, as it handles access requests, the PART 310maintains an entire set of filesystems 1050 for each sub-directory onthe primary 100 and an entire set of filesystems 1070 on the restore140. What appears to the user application (ESX server 1010) to be anordinary filesystem containing ordinary subdirectories is actually avirtual filesystem 1040 wherein any given subdirectory may actually be alink to a separate, associated file system that actually contains the.vmdk files for a given VM.

When these subdirectories are accessed in the virtual file system 1015,the PART 310 thus transparently redirects those accesses to theassociated file system(s) 1050, 1070 on the primary and restore. In oneexample, a make directory (mkdir) command to create VM subdirectory /vm1is intercepted by the PART 310, which then creates file system v.vm1(1050-1) on the primary 100 and its mirror v.vm1 (1070-1) on the restorenode 140. The PART 310 then creates the new file system directory /vm1in the primary filesystem 1040, which is a virtual “mount point” linkingthe subdirectory /vm1 in virtual file system 1015 with its associatedactual file system v.vm1 (1050-1, 1070-1). This link is denoted bypointer 1042. In another example, a write access directed to file/vm0/a1.vmdk is intercepted by the PART 310, which, following link 1041,redirects that write access to the filesystem v.vm0 (1050-0) on primary100 which actually contain the file a1.vmdk. As described in the otherpatents incorporated by reference above, the PART 310 also mirrors writeaccesses to the restore node 140; in this case, the mirrored writeaccess is directed to the filesystem v.vm0 (1070-0) on the restore node140 which actually contains the mirror of a1.vmdk.

In effect, the PART 310 maintains the illusion of a subdirectory tree1011 but actually creates a number of file systems 1050-0, 1050-1,1050-2, . . . , 1050-11, . . . , 1050-n on primary 100 and a number offile systems 1070-0, 1070-1, 1070-2, . . . , 1070-11, . . . , 1070-n onrestore 140.

It is possible that not every subdirectory will be given this treatment,depending on the desirability of having separate access for PART 310 toimplement snapshots of certain subdirectories.

When the need arises to take a snapshot, the snapshot processes runningas part of intelligence 145 can be executed using the standard filesystem oriented snapshot process but using the virtual mount pointinformation to locate the underlying filesystems 1070 associated with agiven subdirectory. In effect, the virtual filesystem (VFS) 1090 hidesthe existence of multiple independent, “container file systems” fromuser application 1010. Subdirectories in the virtual file system (VFS)1090 are accessible as subdirectories, but at the same time theunderlying container file systems 1070 are accessible to the snapshotprocesses. Associated file system snapshot technology in the restorenode 140 can now be relied upon to obtain snapshots of a given VMindependently of snapshots of other VMs, and the restore node 140 canthus treat them as it treats any file system.

In addition, the details of the virtual file system 1090 framework ishidden from the ESX server 1010. In particular, directory-associatedaccess requests made to the system, such as a make directory (mkdir) orremove directory (rmdir) or change directory (chdir) command, areintercepted by the PART 310. Upon receiving a mkdir command, the PART310 layer then issues requests to primary 100 and restore 140 to createthe file system constructs v.vm0 (1050-0, 1070-0), v.vm1 (1050-1,1070-1), . . . , v.vm11 (1050-k, 1070-k), . . . , v.vmn (1050-n, 1070-n)and associates them with links (1041, 1042, 1043) to the actual virtualmachine files and subdirectories as expected by the ESX server 1010.Upon receipt of a rmdir command, the corresponding v.vm structure(s) canbe removed from or edited within the VFS 1090 data structure. Thisshadow virtual file system 1090 is in effect, created and maintained viaprocesses internal to the PART 310. The virtual mount points in VFS 1090are thus accessed by the snapshot processes 1020-1, 1020-2, but thesubdirectory structures remain in place for other I/O requests asreceived from the ESX 1010.

FIG. 12 illustrates a more general case where restore node 140 applies astorage related action 1120 (such as snapshot, de-duplicate,compression, or some other storage related action) to portions of a filesystem (such as a subdirectory 1016) rather than an entire file system1015 created by application 1010. Here, a virtual file system (VFS)layer 1090 in the PART 310 again used to provide links between filesystems and the subdirectories 1011, 1012 associated with these filesystems.

In one such example, the application 1010 may wish to apply ade-duplicate action only to a particular sub-sub-directory 1016. Thus,even when the underlying file systems provided by primary 100 andrestore 140 does not permit such access granularity, a “no de-duplicate”property can be maintained in the VFS 1090 by PART 310 for thatsubdirectory, because it is a virtual mount point linking to an actualunderlying file system 1070-k upon which the property can be applied.

Thus the techniques described herein can be applied wherever it isdesirable to apply a property only to portions (or at some granularitysuch as a subdirectory) of an underlying file system, even when the filesystem itself limits access to such portions or at such granularity.

In another example, the PART 310 may apply properties to the virtualmachine subdirectories in consistency groups. So, for example, the VFS1090 maintained by PART 310 may further indicate that the virtualsubdirectories (1070-0, 1070-1) for two of the VMs (such as /vm0 and/vm1) are to always be treated together and subjected to the samesnapshot policies.

In other scenarios, the VFS 1090 may be exposed to analytics running inthe restore node 140. The results of those analytics can then be used todetermine how to further refine the directory structure(s) 1050 and/or1070. As one example the intelligence process 145 in the restore nodemay detect the application 1010 accesses files in a particular way whichindicates some need to apply a certain scope to a given action. Inanother example, the intelligence 145 may determine that a certainvirtual machine contains a sub-sub-directory /vm5 that is type ofdatabase (a.005.db) having contents that are known to change often andthus will not benefit from compression. Thus intelligence can maintain acompression property when accessing the virtual directory structures inVFS 1090 to exclude sub-sub-directory /vm5 from any compression action.

Cloning with Thin Provisioning and Background Live Restore

It can be desirable from time to time for a user to request thatcomplete duplicate or clone of an existing file system object becreated. In one scenario, a user may wish to create a clone of a priorsnapshot that contains prior obtained intelligence data, to performstill further analytics. In another instance, the clone may be needed torecover a failed file system. In still another instance, the user maysimply wish to copy an object from one file system to another withoutdestroying the original object.

As with the systems described above, in a typical scenario such as shownin FIG. 13, a primary node 100 stores primary data and restore node 140stores associated intelligence data and other information. In oneexample, the object 1215 to be cloned may reside within snapshot(“snap”) 1210; this object 1215 may be a file, a directory or even theentire file system within the snapshot 1210.

The basic idea is that when a clone request 1205 is made to the PART310, it does not simply forward the request to the file systems 102, 142on primary 110 and restore 140 nodes. Instead, a new file system cloneobject 1220 is immediately thin provisioned on the primary node 100 andexposed by the PART 310 to the user (host), and a new file system cloneobject 1230 is also thin provisioned on the restore node 140 (which isconsistent with the system's usual process of mirroring requests to therestore node 140, although that step is not critical to handling theclone request as described herein). The PART 310 therefore does not haveto first actually populate all of the metadata and data to the new filesystem clone objects 1220, 1230. Even without all of the metadata anddata actually being populated, users can start to issue requests toaccess the cloned file system objects 1220, 1230.

As file system requests are made to the clone file system objects 1220,1230, the metadata and data associated with the clone file systemobjects 1220, 1230 are restored as needed. Background processes are alsoemployed to copy metadata and data to the clone file system objects1220, 1230.

The PART level 310 thus coordinates execution of a clone process ratherthan pushing the clone process down to an FS 102, 142 or other filesystem layer in the primary 100 and restore 140 nodes.

A situation where the object to be cloned is a single file will be firstdiscussed in connection with FIG. 14. In this example the file object1300 to be cloned consists of a metadata portion 1310 and a data portion1320. The particular structure of metadata 1310 depends on the type ofunderlying file system, and will be different for a Linux file system,than say, a Windows or MAC OSX file system as is known in the art. Thedata portion 1320 can be considered to be a collection of data bytes ofa certain size, such as chunks 1308 each of 512 kilobytes (kB). A clonefile process executed in PART 310 maintains a clone bitmap 1350 for eachsuch cloned file object 1300. The clone bitmap 1350 includes at least asingle bit 1355 for each chunk 1308 in the file object 1300. The clonebitmap 1350 is used as a tool to coordinate the status of actuallycopying portions of the data 1320 from the original file to the clonedobject.

FIG. 15 is an example flow for a clone process 1400 where the clonedobject is a single file. In a step 1402 a request is received at thePART 310 to create the cloned object. In the next step 1404 a new cloneobject 1220 is created on the primary node 100 and a new clone object1230 is created on the restore node 140, but only thin provisioned,without actually copying any data yet. The thin provisioned file objectsat this point may contain some metadata in state 1406 depending uponwhether or not the underlying file system maintains metadata within thefile object itself (certain operating systems such as Windows and MACOSX do this; other operating systems such as Linux maintain filemetadata as part of a separate inode). In either event, in the nextstate 1408 the bitmap 1355 is created for the file with all bits thereinset to logical “false” value indicating that the corresponding data forchunk has not yet been populated to the clones.

In state 1410 the new clone file objects 1220, 1230 are made accessiblefor subsequent input/output (I/O) requests by the user I/O even thoughno data portion 1320 has yet to be copied from the source snap 1210.

In a next state 1412 a background live restore thread 1420 is started.The live restore thread 1420 may typically be a background threadexecuting only when the PART 310 is otherwise not executing other tasks.In other instances, the live restore thread 1420 may be a thread withlow priority (keeping in mind that the PART 310 is a multi-threadedprocessor as described above).

The purpose of the live restore thread 1420 is to perform the task ofcopying data from the source snap 1210 to the clones 1220, 1230. Thus instate 1422 a next chunk is located. In state 1424 the next chunk iscopied from the source snap 1210 to the clones 1220, 1230. And in a nextstep, the bit in the bitmap associated with that chunk is then set to alogical “true” value. The live restore process then continues as abackground/low priority process as long as and until all chunks of thefile have been copied to the clone.

FIG. 16 shows a typical process 1500 performed when the PART 310receives an access request for a previously thin-provisioned cloneobject. In state 1502 the clone access request is received. In a nextstep 1504, the clone bitmap 1350 associated with the clone object isconsulted. If the bit or bits associated with the chunks accessed in therequest are all set to “true”, then that is an indication that the datahas already been copied to clones 1220, 1230. Processing may proceed tostep 1505 where the access request can be handled as per state 1510.

However if the access request refers to one or more chunks 1308 forwhich the bitmap 1350 indicate a “false” value and thus have not beenpreviously processed, then in state 1506 the bitmap is updated to setthose bits to “true”. In state 1508, data and possible metadataaffecting chunks within the scope of the request are then populated toclones 1220, 1230.

Regardless of whether state 1510 is reached from state 1508 or state1505, the access request is then further handled. As explained above,the access request to the clone may be issued to both the primary 100and restore 140 nodes. The access request may also typically be issuedto the both the primary 100 and restore 140 nodes by the PART 310 usingthe multithreaded log process described above. This then results induplicate copies of the clone 1220, 1230 being eventually instantiatedon the primary 100 and restore nodes 140 once data is flushed from thecaches.

A different process is executed when the object 1210 to be cloned is anobject that includes more than one file, such as a directory or even anentire file system. Such an object, as shown in FIG. 17, may berepresented as a tree or graph structure consisting of nodes and variouslevels with edges connecting the nodes. The node consist of values, suchas metadata defining the content of an associated directory togetherwith a list of references to child nodes and parent nodes that containmetadata for sub-directories and parent directories.

In the example shown in FIG. 17 the snap to be cloned is a rootdirectory with several subdirectories and files stored within thosesubdirectories. The data structure 1600 thus consists of a root node1610, and a first level 1620 consisting of four nodes representing foursubdirectories 1621, 1622, 1623 and 1624. Each subdirectory containspointers or other metadata concerning the files contained within, as isknown in the art. The structure also includes the subdirectory at secondlevel 1630 with further subdirectories 1631 and 1632 and files. Stillfurther subdirectories are located at third level 1630 with respectivefiles.

The initial task when asked to clone such an object is to create a copyof the directory tree structure in the clone 1650 in a particular way.That process 1700 is shown in more detail in FIG. 18 and begins when a“clone directory” request is initially received in state 1702. In a step1704 the PART 310 thin provisions the clone directory such as by onlycreating a copy 1660 of the root node 1610. In the next step 1706metadata associated with the root node 1610 would also be copied as maybe required by the particular type of file system (in the case of aLinux-compatible file system, that may include copying the inode for thedirectory). In state 1708 the clone object is then made available foruser I/O.

In state 1710 a background and/or low priority live restore 1720 threadis kicked off for the directory object. In state 1711 processing maycontinue with the clone appearing to be available for access by the userbut without any data and without even the entire tree structure havingactually been propagated to the clone yet.

The live restore process 1720 for a directory object begins in state1722. Here the directory tree for the original snap 1650 is walked in adepth first search. In the example of FIG. 16, the Depth First Search(DFS) from node 1610 would first located node 1621 for processing, thennode 1631 and then node 1641 before returning to level two and node 1632and so forth. In step 1723 the node that has been located in a depthfirst search is then added to the clone tree.

In state 1724 another background thread is also started concurrentlywith thread 1720. (It is understood that are explained above the PART310 is a multithreaded processor and is capable of executing multipleconcurrent threads at the same time). From state 1725, the backgroundlive restore process 1720 continues to determine if the depth firstsearch locates any additional nodes, and if so, processing loops back tostep 1723 to process the new node. If no new nodes are found in step1725, then in state 1726 a background data restore thread (such as thatdescribed in connection with thread 1420 in FIG. 14) can then betriggered to restore data for the files referenced in the now cloneddirectory tree.

Returning to the background process and Breadth First Search (BFS)thread 1730, here the tree 1600 is then walked in a breadth firstfashion at the current level. In the example of FIG. 17, when node 1621is encountered at level 1620, the breadth first search will next locatenode 1621. In state 1733 a corresponding new node 1671 is added to theclone tree. Processing continues with the test in state 1734 and loopingback to state 1732 until the search of the current level in the tree iscomplete. Once this is done then the BFS background thread 1730 canterminate in state 1735.

Thus as the tree is populated in the clone using both a DFS-orientedlive restore thread 1720 which initiates concurrent BFS-oriented liverestore thread(s) 1730. It is also important to note that neither of thelive restore threads 1720, 1730 actually populate the data content ofthe files in the directory object. It is still the case here that datais populated on only upon (a) actual access to the file (as per process1500 in FIG. 15) or (b) when background restore process 1420 is kickedoff after the tree structures are created.

It should be understood that there is typically some limit on the numberof concurrent BFS threads 1730 at any one particular time, depending onthe available processing power of the PART 310.

The above-described processes, with some adaptation, can alsoefficiently support “temporary” clones 1230. Creation and population ofa temporary clone 1230 may use the same general mechanisms but with anobservation that data in the temporary clone is not meant to bepersisted for long. Thus when the temporary clone 1230 is opened foruser I/O, the actual access might only store modified data in thetemporary clone and continue to access the original snap 1210 for readaccesses. This eliminates the need to restore all of the data in thesnap 1210 to the clone 1230 but a synchronization mechanism can beobserved through use of the bitmap 1350 for each file.

For example the background live restore thread need not be executed forthe temporary clone; similarly, the temporary clone need not necessarilyrecreate all of the data, metadata and directory/subdirectory trees forwhich the user only requests read access. Thus it is only when a userwishes to perform a read-modify-write, the corresponding chunk(s) needto be fetched from the original snap, modified, and then only thosechunk(s) written to the clone.

FIG. 19 illustrates a typical temporary clone access process 1800 inmore detail. It is understood that before this process 1800 is executed,a temporary clone structure has been created such as per the process1500 in FIG. 16. In state 1802 an access request to the temporary cloneis received. In state 1804 a determination is made as to whether or notthe access request is a read or a write.

If the access request is a read, and if the corresponding bits in thebitmap are set to a logic false (indicating that there has been no priorwrite access to those chunks of the temporary clone), then the accessrequest can be serviced in state 1806 from the original snap datastructure 1210.

If the access request is a read, and if the corresponding bits in thebitmap are set to a logic true (bits set) (indicating that there hasbeen a prior write access to those chunks, then the access request canbe services in state 1807 from the clone structure 1230.

If however the access request is a write, then process 1800 proceeds tostate 1808 with bits now being set in the bitmap. In state 1810 data(and metadata if needed) are populated within the scope of the requestto the clone 1230. In state 1812 the PART 310 finishes the writerequest. As before, this may be performed via the multithreaded logprocess in the PART 310.

It is to be understood that the above description is intended to beillustrative, and not restrictive. Many other embodiments will beapparent to those of skill in the art upon reviewing the abovedescription. As but one example, the algorithms specify general steps,or one specific way of implementing a function or feature. Those ofskill in the art will recognize that other approaches are possible. Itshould also be understood that the algorithms described are directed tothe primary logic needed to carry out the stated functions. They do notdescribe all possible variations in implementation; nor do they specifyall possible ancillary functions needed for a practical system such asinvalid user-supplied inputs or invalid operational states. For example,error states can be handled in any convenient way.

The scope of the invention should, therefore, be determined only withreference to the appended claims, along with the full scope ofequivalents to which such claims are entitled.

1. A method for processing in a data-intelligent storage system thatincludes a primary node storing primary data and in-line analytics, arestore node storing further analytics and intelligence, comprising thesteps of: intercepting a request to clone a data object; thinprovisioning a clone object; opening the clone object for access; andcopying data to the clone object only upon the first to occur of: (a) asubsequent access request for the clone object; and (b) as part of abackground restore process.
 2. The method of claim 1 wherein the step ofthin provisioning the clone object further comprises: creating a bitmapdata object containing a bit for each one of a plurality data chunks inthe data object.
 3. The method of claim 2 further comprising: settingbits in the bitmap corresponding to data chunks referred to in thesubsequent access request for the clone.
 4. The method of claim 2wherein the background restore process further comprises: setting bitsin the bitmap corresponding to data chunks as they are copied to theclone object.
 5. The method of claim 1 wherein the data object is adirectory object containing one or more files arranged in at least onedirectory, and the step of thin provisioning further comprises: creatinga tree structure in the clone object that include metadata for the atleast one directory.
 6. The method of claim 5 wherein the backgroundrestore process additionally comprises: initiating a depth-first searchof the directory object to determine subdirectory structures; andstoring metadata concerning the subdirectory structures in the cloneobject.
 7. The method of claim 6 wherein the background restore processfurther comprises, after initiating a depth-first search, initiating abreadth-first search of the directory object.
 8. The method of claim 7wherein the step of initiating a breadth-first search is performed as aconcurrent thread with a thread executing the depth-first search.
 9. Themethod of claim 2 wherein the clone object is a temporary clone object,and further comprising: when the subsequent access request to the cloneis a read access, reading the data object; and when the subsequentaccess request to the clone is a write access, writing data to theclone.
 10. The method of claim 9 additionally comprising: creating abitmap data object containing a bit for each one of a plurality datachunks in the data object; and when the subsequent access request to theclone is a read access, further: reading bits in the bitmapcorresponding to requested data chunks, and when such bits are not set,reading the data object to satisfy the access request.
 11. The method ofclaim 1 wherein the data-intelligent storage system comprises aprotection and analytics (PART) node, and the method further comprises:handling access requests to the clone at the PART node in multipleconcurrently executing threads; assigning a transaction identifier tothe access requests; and logging each access request with its associatedtransaction identifier in a random access, multithreaded log.
 12. Themethod of claim 11 additionally comprising: forwarding access requeststo the primary and restore nodes; logging access requests in a singlethreaded sequential log in each of the primary and restore nodes; andstoring data associated with the access request in a cache memory ineach of the primary and restore nodes.